【レポート】KYBにおけるAWSを活用したIoT-Platformの構築 ~予知保全システムにおけるAmazon SageMakerの活用~ #AWSSummit

【レポート】KYBにおけるAWSを活用したIoT-Platformの構築 ~予知保全システムにおけるAmazon SageMakerの活用~ #AWSSummit

Clock Icon2020.09.16

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

DA事業本部の春田です。

AWS Summit Online絶賛開催中!ということで、本記事では「CUS-35:KYB における AWS を活用した IoT-Platform の構築 ~予知保全システムにおける Amazon SageMaker の活用~」の内容についてまとめていきます。

セッション情報

  • KYB 株式会社 DX 推進部 内藤 孝昌 氏

設計・生産から製品使用時のデータに至るまで、社内のデータ活用を加速させる基盤として、AWS 上に IoT-Platform の構築を進めています。 本セッションでは、その一部である設備予知保全システムを例に、Amazon SageMaker 周辺のサービス活用について重点的に紹介します。

※セッション動画は以下リンク

はじめに

  1. 話すこと
    1. KYBがどんなIoT-Platformを構築中なのか
      1. 「予知保全」中心
    2. AWSをどのように活用しているのか
      1. 「Amazon SageMaker」中心
    3. 話さないこと
      1. 予知保全の機械学習モデル

アジェンダ

  1. About KYB
    1. 会社紹介
    2. KYBのITシステム開発
  2. IoT-Platform
    1. 概要と課題
    2. 予知保全システム
  3. Amazon SageMakerの活用
    1. Amazon SageMakerを使う上での工夫
    2. ML Workflows構築における工夫
  4. Conclusion

About KYB

会社紹介

  • 創立: 1935年3月
  • 創業者: 萱場 資郎
  • 代表取締役社長執行役員: 大野 雅生
  • 売上高: 4,122億円(2018年度実績・連結)
  • 従業員: 15,426名(2018年度・連結)
  • 人々の暮らしを安全・快適にする技術や製品の提供
  • 自動車や新幹線などにもKYB社の技術が使われている

製品図で赤色で示した部品がKYB社製

KYBのITシステム開発

  • 1996年: POPICS
    • MESのシステムで、生産計画の提供や可動率などのKPIの自動計算を担っている中核システム
  • 2000年: 品番チェックシステム
    • ハンディターミナルを用いた部品庫・製品庫などで使用するシステム
  • 2002年: トレサビシステム
    • 製品のシリアルNoと各種情報を紐付けた、トレーサビリティのシステム
  • 2008年: 作業・検査支援システム
    • 手順の提示、計測値の自動収集や判定を行う、組立作業や検査作業を支援するシステム
  • 2013年: QTS
    • 鋳造工場における品質情報を全て収集し、各種分析を行えるようにしたシステム
  • 2014年: 溶接不良検知
    • 機械学習を活用し、時系列データのみで溶接品質をリアルタイムに判定するシステム
  • 2019年: 予知保全
    • クラウドと機械学習をフル活用した、IoT-Platformの一部機能 → 今回の中心

KYB技報No.60の特集記事にて近年の取り組みを紹介

  • 創立80年以上の老舗油圧技術メーカーだが、ITにも取り組んでいる
  • 内藤氏のいるチームの実績では、ほぼ内製
  • チーム内で新規開発・運用しているシステムは数十個

IoT-Platform

概要と課題

  • なぜIoT-Platformか
    • 既存システムの連携状態がスパゲティ
    • そこにIoTデータが増えると破綻

  • IoT-Platformが目指す姿
    • 左側がKYB、右側がユーザー、中央がIoT-Platform
    • ユーザー側の車両データ、KYB側の生産・設計・開発のデータをIoT-Platformに集約
    • IoT-Platform上で、処理・分析・可視化を行うことで以下を実現
      • ①生産性の向上 → KYB
      • ②品質の向上 → KYB
      • ③製品付加価値の向上 → KYB
      • ④新しい価値の提供 → ユーザー

  • 従来はオンプレかクラウドの仮想マシンでPlatformを構築していた
  • オンプレやIaaS
    • 開発コスト ≦ 運用コスト になってしまう
      • ビジネスに注力したい
      • クラスタ管理などに注力したくない
    • スモールスタートができない or 難しい
      • 最初から全てはうまくいかない
      • 素早く構築し、繰り返し改善したい

よりマネージドなサーバレス(FaaS)を中心に採用

予知保全システム

  • 保全の種類は3つ
    • 壊れたら保全する、事後保全
    • 計画的に保全する、予防保全
    • 故障を予知して壊れる前に保全する、予知保全
  • 予知保全は複雑な仕組みになるが、近年のAI・IoTの発展に伴い、多くの製造業で取り組まれている

  • 予知保全システムの全体像
    • 左上がKYBの工場で、設備、センサー、エッジコンピューターがある
    • 工場で収集されたデータは、右側のAWS上に転送され、処理・分析を行う
    • 最終的に故障が予測される場合は、左下オフィスの保全担当者にアラートメールを送る

  • データ収集
    • AWS IoT Coreを中心に、デバイス管理
    • 予知保全用センサデータ例
      • 種類: 振動データ
      • 収集頻度: 30分毎、10秒間
      • データ量: 40MB/ファイル = MQTTでストリーミングできる量ではない
    • 大容量データは得意ではないため、エッジデバイスから直接S3にアップロードして対応
      • 入口にはAWS IoT Coreを使用
      • S3の特定のバケットにアクセスできるRoleを、一時クレデンシャルとして取得
      • トークンを使用してエッジデバイスからS3へデータをアップロード

  • 故障判定
    • エッジとクラウドの2段階で行っているのが特徴

  • 左側がエッジで行う短期故障判定
    • 特徴抽出
    • 短期故障モデルを事前にAmazon SageMakerで学習
    • 学習済みモデルを、GreengrassのML Inferenceの機能を通してEdge側にデプロイ
    • リアルタイムの推論を実現する
    • 生波形は10秒間で40MBといった、非常に大きな容量のファイル
    • リアルタイムの推論によって、サイズの小さな短期故障度ファイルに変換する
  • 右側がクラウド上で行う長期交渉判定
    • 短期故障度ファイルをAWSに転送
    • 10秒のファイルを何個かにまとめて長期的なトレンドを把握し、長期故障判定を行う
    • 故障が予測される場合は、SNSを通してユーザーへ通知

  • 見える化
    • 使い方とコストを考慮し、まずはAmazon Athena採用
    • S3上のデータをAthenaを使って直接クエリ
    • EC2上のTableauサーバーを経由して、ダッシュボードの形で保全担当者へ提供

Amazon SageMakerの活用

Amazon SageMakerを使う上での工夫

  • Amazon SageMakerとは
    • 機械学習のあらゆるワークフローをサポートする、フルマネージド型サービス
    • ラベリング
      • ラベリング支援
    • 開発
      • マネージドJupyter Notebook
      • 主要フレームワークのサポート
    • 学習
      • APIで学習ジョブ
      • 分散学習、チューニングに対応
    • 推論
      • API で推論エンドポイントをデプロイ
      • バッチ推論サポート
    • 使ってみたらかなり便利だったが、最初はうまく行かなくて色々と工夫した
  • 課題1: 使い慣れたエディタで開発したい
    • Notebookインスタンスが提供されているので、普通はそれを使う
    • 学習するときにはコンテナを起動する
    • 開発の序盤、探索的なデータ分析(EDA)を行うときにはNotebookを使用
    • プロダクションのMLコードを開発するときは、使い慣れたエディタで開発したい
  • 解決1: 開発マシンにSageMaker Python SDKを導入
    • オフィスにある自分のパソコンでコーディングが可能
    • 学習したいときは、fitメソッドでクラウド上のSageMakerでトレーニングジョブが起動

  • 課題2: 開発のイテレーションを高速化したい
    • 開発初期はコーディングミスが発生
    • コンテナ起動に数分時間がかかった後にエラーが確認され、効率が悪い
  • 解決2: Localモードの活用
    • トレーニングのジョブをローカルのコンテナで起動できる
    • 開発初期は少量データでローカル開発、高速で開発イテレーションを回す
    • 後半は大量データを使い、AWS上の大規模なインスタンスでで学習
    • roletrain_instance_typeを変更するだけ
    • データもローカルを利用可能

# 通常モード
role = get_execution_role()
train_input = "s3://foo-bar/train_aws.csv"

estimator = PyTorch(entry_point='mnint.py',
                    role=role,
                    train_instance_count=1,
                    train_instance_type='ml.p2.xlarge',
                    framework_version='1.4.0')
                    
##################################################

# Localモード
role = 'arn:aws:iam::xxxxx:role/SageMakerExecutionRole'
train_input = 'file://foo-bar/train_local.csv'

estimator = PyTorch(entry_point='mnint.py',
                    role=role,
                    train_instance_count=1,
                    train_instance_type='local_gpu',
                    framework_version='1.4.0')
  • 課題3: 低頻度の推論を低コストで実現したい
    • 予知保全のような機械学習は、一つのモデルで全ての推論ができることはありえない
    • 似たような設備ごとに個別のモデルが作られることが一般的
    • 30分に1回データを収集している場合は、最速でも30分に1回しか推論を行わない
    • 予知保全で欲しい情報は、10分後でなく、2週間後や1ヶ月後の推論
      • 昨日のデータで1日1回推論したとしても機能する
    • 低頻度の利用では、エンドポイントはリソースの無駄が多い
      • プロビジョンニングの対して、実際に使われているリソースが非常に少ない
  • 解決3: Batch Transform の活用
    • 低頻度かつ非リアルタイムで良いならBatch Transform
    • バッチで推論を行うので、無駄なリソースを削減できる

  • その他: Managed Spot Trainingの活用
    • スポットインスタンスを使ってトレーニングを行う
    • A. スポットの使用フラグと時間を設定するだけ
    • B. 中断対策としてcheckpointを利用可
    • コストが最大で9割減、平均6割〜7割減
estimator = PyTorch(entry_point='mnint.py',
                    role=role,
                    train_instance_count=1,
                    train_instance_type='ml.p2.xlarge',
                    train_max_run=6000,  # A
                    train_use_spot_instances=True,  # A
                    train_max_wait=7200,  # A
                    checkpoint_s3_uri='s3://example-bucket/checkpoints',  # B
                    checkpoint_local_path='/opt/ml/checkpoint',  # B
                    framework_version='1.4.0')
  • モデルの学習は出来たし、推論の確認もした
  • あとは実行して故障通知するだけ?
  • むしろここからが重要

ML Workflows構築における工夫

  • ML Workflowsの実現
    • 機械学習花形のモデリングは全体のごく一部
    • データの収集やリアルタイム推論をどう実現するか、などの管理も必要
    • KYB社は学習のワークフローと、推論のワークフローをどう実現したか?

AWS Step Functionsでお手軽Workflow化

  • 学習Workflow
    • 現在は未実装(あえて人間のオペレーションを挟む)
    • モデル1とモデル2があり、2の方が新しいが、1の方が性能が良い
    • 推論では自動的にモデルを選択したい → タグを活用
    • 任意のタイミングで開発者が学習をかけ、モデル3が生成
    • タグのデフォルトはdev
    • 予知保全ではABテストによる全自動化が難しいため、開発者が評価してタグを切り替えている

  • 推論Workflow
    • モデルごとに動的並列処理
      • 時代に応じてモデルが増える
      • 定期的に推論を行うので、毎回対象が変わってくる可能性がある
    • データの前処理もSageMaker内で実施
      • 前処理(正規化など)も学習データの情報を含んでいる
      • パイプライン化し、バッチジョブで実行している

  • 並列処理のエラーハンドリング
    • Task2がエラーとなった時、CatchしてFailのステートに落としたくなる
    • Failにすると、他の全並列処理が強制終了してしまう
    • → 並列内ではPassで一旦無視する
    • → 並列処理後、エラーのフラグをチェックする

Conclusion

  • Amazon SageMakerまとめ
    • 既に我々にとって必須のサービス
    • 今後は 他部署にも展開していく計画
    • まだまだ進化しており、今後も非常に楽しみ
  • KYBの取り組みまとめ
    • KYBではIoT-Platformの構築を進めている
    • 外注丸投げではなく、内製を中心に取り組んでいる
    • 製品領域への適用も進めている最中

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.